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AMENDMENTS to the DRAWINGS 



No amendments or changes to the Drawings are proposed. 
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REMARKS 

Nature of Amendment 

In the present amendment, we have amended claims 8-13 directed towards a method 
embodiment of our invention, and we cancelled all other pending claims from further 
consideration in this application. Please note that we are not conceding that the subject matter 
encompassed by the cancelled claims prior to this Amendment are not patentable as argued by 
the Examiner in the Office Action. Amendment and cancellation of these claims are made 
solely to facilitate expeditious prosecution of at least a portion of allowable subject matter in 
this application. 

We respectfully reserve the right to pursue claims, including the subject matter 
encompassed by the cancelled claims, as present prior to this Amendment and additional claims 
in one or more continuing applications. 

Objection to the Specification 

Regarding the objection to the specification for not defining the term "computer readable 
medium", these claims have been cancelled from consideration in the present application as 
discussed in the preceding paragraph. 

Objection to Claim 19 

Regarding the objection to Claim 19 for the typographical error, this claim has been 
cancelled from consideration in the present application as discussed in the preceding paragraph. 

Re jections under 35 U.S.C. § 112 

With respect to the rejection of claim 8 for failing to comply with the written description 
requirement regarding disclosure of our real-time attribute being in a format incompatible with a 
directory access request return format and then to receive compatible format, we respectfully 
disagree and ask the Examiner to reconsider our disclosure, especially at (paragraph numbers are 
as published by the USPTO): 

[0004] In the 1970s, many proprietary communications, computing, and 
data storage systems developed were incompatible with each other . 

[0011] Practically every major supplier of computing platforms, be it 
operating systems, storage solutions, or entire enterprise computing 
environments, has a directory service product . However, many of the 
early directory service products and protocols were also proprietary and 
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incompatible from one vendor to another. 

[0012] In 1988, the CCITT created the X.500 standard for directory 
services. X.500 organizes directory entries in a hierarchical name space 
capable of supporting large amounts of information. To ease the information 
retrieval process, it also defines the powerful search capabilities. Therefore, 
X.500 is often used together with add-on modules for interoperation 
between incompatiable directory services because of its functionality and 
scalability. 

[0057] FIG. 4 provides an example of two applications accessing values of 
attributes in an LDAP directory with further illustration of converting 
dynamic data for storage as static data in the LDAP directory . 

[0087] It is important to note that the value "82 F" was never actually stored 
in or retrieved from the LDAP directory. In this manner, the handling of 
dynamic data is transparent.- any requesting client, thereby providing a 
powerful extension to the directory server protocol to allow reading of 
dynamic data without changing or extending the protocol itself (e.g. client 
applications are backwards compatible to our improved directory server). 

[0137] (e) the interface between the requesting application client and the 
directory server is unchanged, allowing backwards compatibility with 
legacy applications and protocol stacks ; and . . . 

We believe our discussion of the history of incompatible directory servers and the 
evolution of open directory access protocols such as LDAP is likely sufficient for one of 
ordinary skill in the art to interpret our term "compatible" and "not compatible" with such a 
protocol. We have disclosed obtaining a data value from a source outside an LDAP directory, 
and thus it would not be in a format yet to either be stored in the LDAP directory or returned as a 
return parameter to a LDAP access request. So, we have also disclosed converting that value to 
a format compatible with a directory access protocol return parameter. 

We respectfully request reconsideration of this rejection. 



Rejections under 35 U.S.C. §101 

Claims 1-7 and 14 - 19 have been cancelled from further consideration in the present 
amendment. 
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Rejections under 35 U.S.C. §103(a) 

Regarding the rejections of Claims 8-13 under 35 U.S.C. § 103(a) over previously-cited 
Sanchez in view of newly-cited Patel, we respectfully maintain our previous arguments and 
position regarding the teachings of Sanchez, as set forth in previous replies and amendments. 

Regarding Patel, we believe Patel may not provide any conversion from a non-directory- 
access-protocol format to a format compatible with a directory access protocol (i.e. LDAP or 
X.500). For example, Patel states (our emphasis adde): 

"The format and type of content (including functions permitted on this 
channelidevice) presented will be based on this identification. This 
component, nevertheless, does not do any modification to the content 
or participate in delivery of the content. " (Patel, 1J0074) 

In the Office Action, it was reasoned that Patel's 1)1056 disclosed an external value 
fetcher. There is no Tf 1056 in Patel's disclosure; we believe this is a typographical error intended 
to refer to 1(0156. In 1(01 56, there is a disclosure of an "interface dictionary", which defines 
which attributes must be fetched in "real time or in batch mode", and it defines how often (e.g. 
"frequency") the real time values should be updated. 

As we best understand Patel's disclosure, they use an "adapter" to retrieve data external 
from their LDAP directory, as described at 1fl( 0148, 0154, 0155, and 0166. However, we 
believe these paragraphs describe how external values are retrieved and then stored in their 
LDAP directory. Then, when a client requests that same information from the LDAP directory, 
it is retrieved from the LDAP directory and returned to the requester. 

This presents several problems we have solved with our invention. First, if Patel's 
"frequency" parameter in their "interface dictionary" is a low value, when a requester requests a 
real time value, it may be relatively stale. Our invention, as claimed, always retrieves a fresh, 
current value from the real time source, not from within the LDAP directory. Thus, our 
invention actually returns the "real time" value to the requester, whereas we believe Patel's 
invention may return a value which was, at one time, real time but may have since grown stale. 

Second, update operations made to attributes stored in LDAP directories consume 
considerable processor time and memory. So, if a real time value varies rapidly over time, and 
especially if many requesters are requesting the real time value in a short period of time, we 
believe Patel's invention's "adapters" will be updating LDAP attributes very often (if their 
"frequency" parameter is set appropriately to reflect actual real time values). As such, an LDAP 
directory containing (or referencing) very many real time external values will suffer serious 
performance issues under maximum load, such as slow response time, exceeding memory 
allocation, etc. We believe Patel's invention stores their retrieved real time values directly into 
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an LDAP directory (see Abstract, IfflOOlO, 0012 - 0014, 0065, 0067, 0071, etc.). 

Our invention actually avoids storing the real time data in an LDAP or X.500 directory, 
thereby avoiding the processing hits of performing LDAP updates to attributes to hold the real 
time data. Instead of a process such as Patel's, our invention actually returns the retrieved and 
converted real time value directly to the requester, along with any non-real time data from the 
LDAP directory that was requested. This is why we have disclosed and claimed "converting" 
the value to a format compatible with a directory access protocol return - so that when the 
requester receives the returned parameter set, all of the data, including the real time value, will 
appear to have come from within the LDAP directory. Thus, "backwards compatibility" is 
achieved, while saving considerable processing resources and allowing large numbers of real 
time values to be associated with other LDAP directory-stored data (e.g. relatively static data). 

We respectfully ask for the Examiner's reconsideration of these rejections over Sanchez 
in view of Patel. 

Ordinary Skill Level. We are respectfully requesting an explicit determination by the 
Examiner of what is being considered to have been the ordinary skill level in the relevant art(s) 
at the time of our invention, and that analysis be placed into the record of examination. We 
believe this is critical to any argument or holding of obviousness, because it is not possible to 
determine what would have been obvious to do without quantifying the skill level of who would 
have found it obvious to do. 

The Court reasoned in In re Gentile (Civ. App. No. 93-1086 (Fed Cir. Oct. 5, 1993)), that 
unless an explicit level of ordinary skill in the art is established during examination of a patent 
application, the ordinary level can be presumed from that which is indicated by the cited art. 

More recently, the Court in KSR v. Teleflex reiterated the importance of "resolving" the 
ordinary skill level using objective analysis when applying 35 U.S.C. § 103(a) in a rejection, as 
set forth in Graham v. John Deere Co. of Kansas City, 383 U.S. 1,17- 18. The Court mKSR 
clearly stated the need for explicit analysis to be made of record (our emphasis added): 

". . . To determine whether there was an apparent reason to combine the 
known elements in the way a patent claims, it will often be necessary to 
look to interrelated teachings of multiple patents; to the effects of 
demands known to the design community or present in the marketplace; 
and to the background knowledge possessed by a person having 
ordinary skill in the art . To facilitate review, this analysis should be 
made explicit . ..." 



Please note our points in our previous reply that Messrs. Sanchez and Wang (Sanchez et 
al.) do not appear to persons of ordinary skill in the art, whereas there is no evidence or analysis 
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of record that indicates that it was ordinary to possess the ingenuity indicated by the number of 
issued patents and published patent applications as possessed by these two inventors. Please also 
note that we requested an explicit analysis of skill level in our last reply, but we are unable to 
find a response to our request in the present reply. 

With respect to Messrs. Patel and Caiazzo and Ms. Holme (e.g. Patel, et al.), we find 
similarly that, according to the USPTO's online database, they are named individually or in 
combination in three issued US patents and three published patents pending. As such, we do not 
believe it would be appropriate to simply rely upon their disclosures as indicating the ordinary 
skill level in the art because this is no evidence of record that ordinarily skilled persons obtain 
three or more patents. 

We contend that obtaining a patent is a relatively rare and distinguishing factor in the 
career of an engineer or scientist. Thus, we believe, and it appears the Courts hold, that explicit 
analysis of ordinary skill level should be placed in the record to facilitate future review of a 
rejection under 35 U.S.C. §103(a) should it be necessary. 

For these reasons, we respectfully submit that wc believe the cited art is drawn from 
inventors of extraordinary skill in the art, and thus their teachings do not indicate what was 
ordinary skill at the time of our invention. We are requesting an explicit determination of the 
ordinary skill level at the time of our invention. 

Request for Indication of Allowable Subject Matter 

We believe we have responded to all grounds of rejection and objection, but if the 
Examiner disagrees, we would appreciate the opportunity to supplement our reply. 

We believe the present amendment places the claims in condition for allowance. If, for 
any reason, it is believed that the claims are not in a condition for allowance, we respectfully 
request constructive recommendations per MPEP 707.07(j) II which would place the claims in 
condition for allowance without need for further proceedings. We will respond promptly to any 
Examiner-initiated interviews or to consider any proposed examiner amendments. 



Respectfully, 




Robert H. Frantz, Reg. No. 42,553 
Agent for Applicant 
Tel: (405) 812-5613 
Franklin Gray Patents, LLC 



